perf(ci): add pub-substring fast path before Rust API regex scan - #1812

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

Merged main (a9aeee8f, which included #1870) into this branch to resolve the dirty mergeable_state — one real conflict in tests/test_pr_review_autofix_nvidia_nim_contract.py where this branch's own already-merged cron-drift fix (test_review_fix_caller_runs_once_each_day, guarding against the retired 23 */2 * * * cadence) collided with #1870's freshly-merged rename of the same test (test_review_fix_caller_keeps_the_github_daily_recovery_slot, guarding against the retired 23 * * * * cadence). Resolved by keeping #1870's name/docstring and preserving both historical negative-cadence assertions — they aren't contradictory, both guard against previously-retired schedules.

Evidence on the merged head (72ce2f89):

• coverage run -m pytest tests -q → 2854 passed, 1 skipped, 21 subtests passed
• coverage report → 99% (95 missed statements), all in scripts/ci/review_admission_controller.py, confirmed pre-existing on unmodified main@a9aeee8f (identical 95-statement/77-branch-part miss count reproduced from a clean main checkout) — not introduced by this PR. This PR's own touched file, scripts/ci/opencode_review_surfaces.py, is at 100%.
• interrogate → 98.5%, same pre-existing-on-main gap (confirmed 98.3% on clean main too, in the same module).

Pushed non-force to fix/rust-api-symbols-pub-fastpath (b44a1562 → 72ce2f89, fast-forward, no rebase).

🤖 Generated with Claude Code

Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01BV96rXhqoR3tYZ9AeAVur4

Generated by Claude Code

agent-review-runtime-quality failure at 79c436d9 — inherited, not this PR's; already fixed by the branch update c9244ceb.

The two failures (test_inspect_pr_closes_empty_pull_request_even_if_the_comment_call_fails, test_main_reconciles_the_durable_admission_gate_when_a_state_path_is_given) are in tests/test_pr_review_merge_scheduler.py, which this PR does not touch. The merge-base was one commit before #1922 (f2506388), whose 10-line monkeypatch of recover_current_head_startup_failures is exactly what those tests were missing.

Why it did not reproduce locally at first: the call is gated at scripts/ci/pr_review_merge_scheduler_core.py:4172 on os.environ.get("GITHUB_ACTIONS") == "true". With that variable set, the head reproduces both failures (2 failed, 324 passed); the merge with main passes (326 passed).

Verification on a tree identical to c9244ceb (same parents 79c436d9 + f2506388, git diff --stat empty): coverage run -m pytest tests → 2892 passed / 1 skipped, coverage report --fail-under=100 → 100%, interrogate → 100%. My own push of the same merge was rejected by --force-with-lease because the bot had already landed it — nothing further to push.

CodeQL compatibility analysis (python) / (actions) failing on c9244ceb — nothing to fix on this branch; the failure is the designed pending-verdict state and its resolution is upstream.

What the shard job actually printed after its last ##[endgroup] (job 101325644739, 16:25:11Z): CodeQL scan dispatched. The dispatch workflow will rerun this exact failed CodeQL job after publishing its terminal verdict. — the shard fails itself by design and waits for codeql-scan-dispatch.yml to publish a verdict and rerun it.

That dispatch chain is blocked in two places, neither in this PR:

1. codeql-scan-dispatch.yml has 106 runs queued and 0 successes ever (codeql-scan-dispatch.yml has never run: env: cannot hold the client_payload matrix array (0 success / 136 failures since #1776) #1925; the env: array bug was fixed by fix(codeql): serialise the dispatched scan matrix with toJSON #1926 / 3f88e13a), and the two dispatches this head fired (33977807975, 33977874646, 16:25–16:26Z) are still queued.
2. When a dispatch does run it is rejected at the actor gate — the most recent one (33973205474, 16:25Z) printed repository_dispatch authorization rejected actor=opencode-agent[bot] sender=opencode-agent[bot] because both must match one configured scheduler identity. The gate now accepts a list (fix(dispatch): parse the trusted-dispatcher allowlist identically in all three consumers (#1929) #1932), but the OPENCODE_REPOSITORY_DISPATCH_ACTOR variable is still the single value github-actions[bot] (opencode-review-dispatch rejects the current dispatcher identity: allowlist says github-actions[bot], sender is opencode-agent[bot] #1929, owner action).

So these two contexts will go green on this head only after the variable is set and the dispatch drains. No commit pushed for this event. Context on the wider queue mechanics: #1935.

noema-review failing on c9244ceb — gateway transport, not a review verdict; nothing to fix on this branch.

Job 101325475710 (16:33:45Z → 17:10:19Z) held a runner for 26 minutes and ended in Prepare Noema model verdict with: Noema gateway transport failed: HTTPError: HTTP Error 502: Bad Gateway; caller attempts=1, duration=1584.9s, phase=response_error, served_model=deepseek-ai/deepseek-v4-flash-0731 (the gateway owns repair/failover; the caller does not retry by policy). No Noema review was posted on this PR, so there are no findings to address.

This is the CO gateway 502 class tracked in ContextualWisdomLab/contextual-orchestrator#1045; the current root-cause chain for it — the review launcher stripping OpenRouter rows so the sidecar pool is NVIDIA-only and cannot fail over — is #1476 (see #1938). Together with the two CodeQL shards above, all three failing contexts on this head are upstream of the PR. No commit pushed for this event.

Correction to the noema note above: the "launcher strips OpenRouter rows" chain was retracted by its author after a source check on the pinned contextual-orchestrator (2e414d15: OpenRouter rows carry evidence_only=False and pass through), so #1476 is a hardening for a regressed pin, not today's lever. The current explanation for the NVIDIA-only pool is scripts/ci/contextual_orchestrator_review_sidecar.sh:43 exporting ORCHESTRATOR_CATALOG_ACCOUNT_CAP with default 8 while the policy default is 4: the 12-route catalog fills alphabetically with 8 nvidia_nim + 4 nvidia_nim_sub and never reaches openrouter, which matches the 8+4 in every preflight log. A fix is being prepared in that lane (#1938 thread). The classification of this PR's failure is unchanged: gateway 502, nothing to change here.

Recovery push: merged main@f2f91b80 into this branch — 2c6654f2 (clean, 0 conflicts; gate on the merge: 2898 passed / coverage 100% / interrogate 100%).

Why a push and not a re-run: the strix job on c9244ceb (16:22–18:03Z) ended with Strix could not complete authoritative vulnerability analysis because its provider/backend was unavailable — the single-upstream sidecar stall that #1939 (f2f91b80, merged 17:25Z) fixes. Runs bind the sidecar at creation time, so re-running the failed job would execute the pre-#1939 sidecar; a new head gets the current one. The noema-review 502 on the old head is the same class.

What this does not fix: opencode-review failed with No APPROVED or CHANGES_REQUESTED from opencode-agent on the current head. The dispatch workflow will rerun this failed job after publishing an authenticated exact-head verdict, and the two CodeQL shards are in the same designed pending state — all three wait on the dispatch actor variable (#1929, owner action). With #1937 on main, the new head's queued checks will not be cancelled by a pre-review branch update.

noema-review on 2c6654f2 (job 101388340002, 23:44–23:55Z): HTTP Error 503: Service Unavailable after duration=471.3s, served_model=deepseek-ai/deepseek-v4-flash-0731, caller attempts=1 — gateway transport again, nothing to change on this branch. Note for anyone reading it as evidence for the observability lane (#1943/#1944/#1945): this run was created at 21:28:37Z with TRUSTED_SOURCE_REF f2f91b806, i.e. before that lane landed (22:15:08Z), so it has no noema-sidecar-evidence artifact by construction — runs bind the sidecar at creation, not at start. The next Noema run created for this head after fe827e13 is the first one that can carry the per-route trace. No commit pushed.

strix failure on 2c6654f2 (run 33993155419, job 101388543976) — not caused by this PR; no push.

What the strix-reports artifact shows (read by three independent refutation passes, none refuted):

• The scan ran 23:51:57Z → 02:19:18Z (9014 s, 824k input tokens, 16 successful turns out of 72 LLM calls) and died when the sidecar gateway answered the agent's chat/completions with HTTP 500 {'error': {'code': 'internal_error'}} (request_id 808750c3…) for the sixth burst in a row; strix's cumulative per-agent replay budget (5) was already spent at 00:13, 00:26, 01:24, 01:37 and 02:02. No strix-side limit fired: max_turns 500 never approached (highest turn 9), no idle/total timeout, sandbox teardown came after the failure.
• 500 internal_error is contextual-orchestrator's generic unhandled-exception path (server.py at the sidecar's pin 464da471: except Exception: traceback.print_exc(); _send_error(500, "internal_error", …)), not a relayed provider error — those go through ProviderUpstreamError → 502 api_error with agent/model/provider_status in detail, and that relay path was live in the same run (3 × status=503 service_unavailable). The sidecar stderr carries 83 request_failed status=500 code=internal_error lines and one sidecar emitted an unexpected exception line (the sanitizer collapses every traceback into that one line, so the exception type is not recoverable from this run). Each 500 arrived ~90 s after its request (first after 272 s), i.e. at the end of a serving walk.
• Preflight served 4/12: both NVIDIA keys' deepseek-v4-flash + deepseek-v4-pro; gemma-3-12b/4b answered 404 on both keys; all four OpenRouter free routes answered 429. That is the catalog shape fix(sidecar): fill the preflight served set lazily to a readiness target #1949 (lazy fill) is fixing.
• This PR changes scripts/ci/opencode_review_surfaces.py (a 2-line early-continue) and five test files; the run executed the base branch's trusted strix.yml / strix_quick_gate.sh / sidecar, none of which the PR touches, and the changed file is only the scan target.

Follow-ups: the sanitizer now needs to keep the exception type and innermost contextual_orchestrator frame per traceback (PR coming from the observability lane), and the unhandled exception itself is a contextual-orchestrator serving-path defect to file once a typed line exists. The branch is behind; the scheduler's pre-review refresh will bring in main once checks are terminal, so no manual merge push from here.